home *** CD-ROM | disk | FTP | other *** search
/ BBS Toolkit / BBS Toolkit.iso / rbbs_pc / rbbs174.zip / 174MSG.DOC < prev    next >
Text File  |  1992-06-23  |  3KB  |  70 lines
  1. Version 17.4 of RBBS-PC optionally supports a new format of the
  2. message file, in order to support carbon copy.   There are only
  3. two changes:
  4.  
  5. (a)  byte 67 now contains the number of headers in the message.
  6.      For i = 1,2,3,...255, the character whose ascii value is i
  7.      is stored in that postion. E.g. a tab there means 9
  8.      headers, 1 header is the white smiley face.  Hence there
  9.      is a maximum of 255 headers.
  10.  
  11. (b)  there can be more than one header in the message, per byte
  12.      67.   The difference between the headers reflects who the
  13.      message is TO.   The same message can be to multiple people.
  14.      At the time the message is created, all the message headers
  15.      are identical except for
  16.  
  17.        o  who the message is to
  18.  
  19.      Note that all the message headers have the same message #.
  20.      As the messages are read, two other fields may differ:
  21.  
  22.        o  the field marking when the message was received.
  23.  
  24.      Each header is independently marked.
  25.  
  26.        o  the status byte of the message.
  27.  
  28.      Each header can be independently killed.
  29.  
  30. Byte 67 of pre-17.4 message bases have a blank in byte 67, which
  31. would ordinarily mean 32 header records.   However, both RBBS-PC.EXE
  32. and CONFIG.EXE are written with a "fail-safe" check to determine
  33. whether the alleged record really is a header, and will correctly
  34. read all message bases written by 17.4 and earlier versions.   The
  35. check employed is that true header records must have
  36.  
  37. o   byte 116 must contain ascii value 225 or 226
  38.  
  39. If you want to be extra sure, you can also insist that
  40.  
  41. o   bytes 70 and 73 must contain a "-" (part of date).
  42.  
  43. RBBS-PC works the following way with messages with multiple headers:
  44.  
  45. o   the individual header is removed in a purge when it is marked as
  46.     killed and the count of the number of headers is reduced by one.
  47.  
  48. o   the body of a message is not removed in a purge until all headers
  49.     are killed.
  50.  
  51. o   if any header is to the person reading, that header controls the
  52.     access of the person.   If that header is killed, for example,
  53.     the person can no longer read the message at all, unless the
  54.     person has sufficient security to read/kill all mail.   If the
  55.     killed message is public, the person can read the message but
  56.     it will be treated as someone else's mail.
  57.  
  58. o   when the caller says to kill a message, the caller can kill at most
  59.     the controlling header, unless the caller can read/kill all mail,
  60.     in which case the caller is individually asked to confirm the killing
  61.     of each header after being told the message number and who it is to
  62.     (though it would certainly be permissable to give the option to kill
  63.     all of them at once).
  64.     
  65. o   "et al." is added to the display of the message header, at the end
  66.     of who the message is to, when the message is to more than one person.
  67.     The "et al." is NOT stored in the message header.   Each person
  68.     the message is to sees the "et al." after their own name.  "et al."
  69.     is Latin for "and others".
  70.